POV-Ray : Newsgroups : povray.off-topic : The next evolution in P2P : Re: The next evolution in P2P Server Time
6 Sep 2024 07:19:34 EDT (-0400)
  Re: The next evolution in P2P  
From: Darren New
Date: 10 May 2009 17:11:37
Message: <4a074309$1@news.povray.org>
Gilles Tran wrote:
> I still don't understand how that would protect the owners of the search 
> engine from litigation.

It probably wouldn't, but it might help. Just like it helps having P2P 
instead of centralized warez sites helps prevent the copyright owners from 
taking stuff offline.

> If a user can get a pointer to get some illegal 
> content, the party that provided the pointer can be found liable,

Well, sure. The owners would have to not blatantly acknowledge that they're 
helping distribute copyrighted files.

The benefit is that if someone comes and confiscates your servers, there's 
zero information on the server that would say any of the links are to 
copyrighted material. It would be like a site full of tinyurl URLs getting 
sued for pointing at copyrighted information.

> least if they didn't show due diligence in cleaning up their 
> index/tracker/whatever. 

And how would you do that, without downloading every torrent posted to your 
own server without

> How would your system work in practice (from a 
> user point of view) ?

I'm guessing you could make it look a lot like bittorrent does right now. 
For example, the protocol could be changed that if you include a file called 
README or MANIFEST or some such, that file gets hashed into a bloom filter 
and the result is tacked onto the .torrent file. (You'd probably have to 
take the file names *out* of the .torrent file and put it into a file inside 
the torrent data itself.)

When you wanted to do a search, you put in your search terms, your *client* 
generates a bloom filter, sends it to the search server, which looks thru 
its torrents to find matching ones, and sends the matching torrents back to 
you. The client would then connect to each such torrent, download the 
README/MANIFEST/whatever file, make sure the bloom match worked, and if so, 
show it to you and ask if you want to download the rest of the stream.

The server, in the meantime, shouldn't return too many search results, to 
prevent attackers from doing offline searches of the bloom filters. I.e., 
the server needs to make sure there are significant amounts of search text 
(as in, enough bits set to imply s sufficiently long search string that 
you're unlikely to get too many false positives) in the incoming filters.

Of course it's not going to be complete protection. It's another layer of 
plausible deniability just like DHT is. The only good solution is a good 
distributed search algorithm. Bloom filters just make it possible to do a 
full-text search without any party knowing what you're searching in or what 
you're searching for.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.